Description

Closes #7616

Using a type alias for an array (type ArrayU8Len2 = [u8; 2]) as a struct field and then comparing two such structs with == triggered an ICE: "Const generic not materialized". The Eq impl for arrays is generic over the length N, so resolving it needs the alias to carry its concrete length down into the const generic machinery. Two spots dropped it on the way.

extract_type_parameters now pulls the length out of array types the same way it already does for structs and enums: when the original side carries an ambiguous length variable (N) and the concrete side has a literal, N gets bound to that literal. MaterializeConstGenerics for TypeId also handles TypeInfo::Alias now, recursing into the aliased type instead of stopping at the alias, which mirrors the existing Ref handling.

The new e2e test exercises array aliases and nested aliases ([ArrayU8Len2; 3]) as struct fields, equality comparison to hit the Eq const generic path, and Vec<Alias>::get().unwrap() return-type resolution. Existing type_alias*, const_generic*, and array* suites still pass.

Checklist

• I have linked to any relevant issues.
• I have commented my code, particularly in hard-to-understand areas.
• I have updated the documentation where relevant (API docs, the reference, and the Sway book).
  • If my change requires substantial documentation changes, I have requested support from the DevRel team
• I have added tests that prove my fix is effective or that my feature works.
• I have added (or requested a maintainer to add) the necessary Breaking* or New Feature labels where relevant.
• I have done my best to ensure that my PR adheres to the Fuel Labs Code Review Standards.
• I have requested a review from the relevant team or maintainers.